fix(dream-cli): template apply resilience + restart cache invalidation#935
Conversation
Lightheartdevs
left a comment
Lightheartdevs
left a comment
There was a problem hiding this comment.
Three reasonable fixes bundled:
-
docker compose restart→docker compose up -d: correct.restartreuses the existing container (baked env);up -drecreates with fresh env from.env. This is the canonical way to pick up model/config changes. -
( cmd_enable "$svc" )subshell in template apply: isolatesset -euo pipefailso one service failure doesn't kill the loop. The|| warnalready handles the failure message — the subshell is needed to make it actually work. Subtle but correct. -
Fallback to
resolve-compose-stack.shindream-macos.sh: good — when.compose-flagscache is missing, falling through to static overlay list would miss user-installed extensions. Delegating to the resolver fixes that.
All three are small, correct, and well-motivated. Ship.
Combines two dream-cli and extensions-related fixes: 1. Template apply exit trap (Light-Heart-Labs#903): wrap cmd_enable in a subshell inside _template_apply so a failing extension doesn't abort the entire template — the loop continues to the next service. 2. Restart + cache invalidation (Light-Heart-Labs#904): dream-cli restart uses docker compose up -d (recreates containers) instead of restart (which doesn't pick up .env changes). macOS dream-macos.sh gets dynamic compose flag resolution. Extensions enable endpoint invalidates .compose-flags cache on stopped-start path so dream-cli picks up the newly-enabled extension. Replaces: Light-Heart-Labs#903, Light-Heart-Labs#904
Lightheartdevs
force-pushed
the
combine/dream-cli-fixes
branch
from
6853228 to
74df78a
Compare
2 participants
Combined PR replacing #903 and #904. See commit message.
Replaces: #903, #904